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Frame synchronisation mechanism 

Background of the invention 

The invention relates to methods and equipment for synchronisation 
of frames which are transmitted over multiple parallel transmission paths in a 
5 telecommunications network. 

Fig. 1A illustrates a telecommunications network in which the inven- 
tion is applicable. The telecommunications network could be e.g. a so-called 
third generation cellular_mpbile network, such as UMTS (Universal Mobile 
Telecommunications System). The telecommunications network comprises a 

10 first end node, such as a mobile station MS, and a second end node, such as 
a Radio Network Controller RNC1 , RNC2. The network also comprises several 
middle nodes, such as Base Stations BS1 to BS4. Information to be sent be- 
tween the end nodes is formatted as frames and at least some frames are 
sent between the end nodes via at least two middle nodes. The first middle 

15 node via which a connection between the end nodes is established is called a 
first middle node. The other middle nodes, which are added later to the con- 
nection, are called second middle nodes. In cellular network technology, the 
technique of routing frames via several middle nodes is called macrodiversity, 
diversity combining or soft handover. 

20 Fig. 1B illustrates a problem associated with the system as shown 

in Fig. 1A. From this point on, the invention will be described using concepts 
and terminology from cellular networks, especially UMTS, but it should be kept 
in mind that the invention is applicable to other telecommunications networks 
where the middle nodes (the base stations) are not synchronised with each 

25 other and/or the end nodes (MS, RNC). In other words, the different nodes do 
not use a common timing reference and/or frame numbering sequence. How- 
ever, recent UMTS literature favours the term User Equipment (UE), but in this 
application, the term Mobile Station (MS) will be used. 

According to the current vision of UMTS, some traffic overhead is 

30 eliminated by not transmitting frame numbers with the frames (i.e. on a traffic 
channel) over the radio interface Uu. Instead, in the BS to MS direction, the 
frame numbers are broadcast to all mobile stations simultaneously, and in the 
BS to RNC direction, the base stations add the frame numbers in a modulo-p 
sequence where the currently proposed value for p is 72. In other words, the 

35 frame numbers repeat cyclically: 0, 1, 71, 0, 1, etc. The base stations are 
not synchronised with each other. Therefore, the frame numbers are relative 
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and, indeed as such, they are meaningless without at least an implicit informa- 
tion about the timing reference to which the frame numbers are based. De- 
pending on the point of view, the frame numbers are called MSFN. BS1FN, 
BS2FN, etc. In Fig. 1B, time advances from top to bottom. At time TO, the Mo- 
5 bile Station MS receives a frame which the MS interprets as frame number N. 
Because the mobile station's timing reference, i.e. its clock, is the master tim- 
ing reference, the RNC must have sent this frame sometime before TO. This 
"sometime" is called Timing Difference Tdiff and it is due to the finite propaga- 
tion and processing delays-between the RNC and the MS. (The concept of the 

10 transmission delay is somewhat analogous to the timing advance in a GSM 
system, but in GSM, the timing advance of the MS is adjusted.) 

At time TO, the MS also sends an uplink frame to the RNC. This 
uplink frame is also numbered N because the frame numbering is based on 
the mobile station's timing reference. Under each node (MS, BS1, BS2) is 

15 shown the corresponding timing reference, or frame numbering sequence 
(MSFN, BS1FN, BS2FN). Approximately at time TO+Tdiff, the RNC receives 
the frame N via two base stations, BS1 and BS2. Because the frame number 
is not transmitted over the radio interface, and because the base stations use 
different timing references, BS1 sends this frame to the RNC as frame N\ 

20 whereas BS2 would send the same frame as frame N". The RNC does not 
have an intrinsic timing reference. 

Although the first problem is most severe in a system using 
macrodiversity, the underlying problem of BS/RNC synchronisation also oc- 
curs without macrodiversity. 

25 A second problem is that in some telecommunications systems, 

such as UMTS, the connection can be reconfigured, e.g. for negotiating a dif- 
ferent data rate. Such reconfiguration must take place simultaneously at all 
nodes involved in the connection. 

A third problem is that in systems using encryption, the frame num- 

30 ber is often used as a constantly varying cipher key. However, a moduIo-72 
frame number is too short for reliable ciphering. 

Disclosure of the invention 

An intermediate object of the invention is to provide a mechanism 
for solving at least the first problem above, i.e. MS/BS/RNC synchronisation. A 
35 final object is to solve also the other two problems relating to simultaneous re- 
configuration and ciphering. 
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The intermediate object is achieved with a method and the equip- 
ment which are characterized by what is disclosed in the attached independ- 
ent claims. Preferred embodiments for solving the other two problems are dis- 
closed in the attached dependent claims. 
5 The invention is based on locating a novel problem (in existing 

macrodiversity implementations, the base stations are synchronised and the 
problem does not exist). The invention is also based on an idea which can be 
implemented as a method comprising the steps of: (1) establishing a connec- 
tion-specific timing reference (called CFN) which is common to all nodes in- 

10 volved in the connection; (2) determining, for at least one base station, an off- 
set which is related to the difference between the timing reference of the base 
station in question and the CFN; and (3) using the information about the offset 
to compensate for the difference between the timing references. 

According to the invention, it is proposed that the Mobile Station MS 

15 and the Serving Radio Network Controller SRNC must agree on a common 
timing reference which comprises at least a common frame numbering 
scheme. Within the context of this application, 'common 1 means common to 
the connection between the MS, the SRNC and the intervening base sta- 
tion^). Such a common frame numbering scheme is called Connection Frame 

20 Number CFN. 

According to a preferred embodiment of the invention, the offset is 
used by the at least one base station, for synchronising its timing reference to 
that of the RNC. 

Using the common frame numbering scheme, i.e. the CFN, means 
25 that when the SRNC decides to send data to a Mobile Station MS, it marks the 
frame with a frame number of X. When the Mobile Station receives the frame, 
it identifies the frame as frame X. However, the actual frame number is not 
transmitted on the traffic channel, and correspondingly, the common frame 
numbering scheme must be agreed on while establishing a connection. In 
30 other words, the MS and the SRNC must synchronise their frame numbering 
schemes at the beginning of the MS activity. In other words, MS and the 
SRNC must synchronise with each other during the exchange of the first few 
messages of the connection. The MS/RNC synchronisation can be base on a 
separate synchronisation message, if desired, but a separate message for this 
35 purpose is superfluous if the following mechanism is used: The first message 
which the MS sends is typically a Connection Request message. It comprises 
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the measurement of the cells which the MS proposes to include in its active 
set, i.e. its set of active cells/base stations. According to the invention, the ini- 
tial message also comprises information concerning the difference between 
the timing references of the various base stations. The difference between the 
5 MS's timing reference and that of base station number n will be called OFSn. It 
is measured for each base station monitored by the MS. 

The SRNC determines the common reference from the point of time 
when it receives the initial Connection Request from the MS. When the 
SRNC orders the base station(s) to establish dedicated channels for the MS, 

10 the SRNC also sends to the base station the corresponding BS-specific offset 
OFSn. In every downlink frame, the SRNC includes a frame number according 
to the common frame numbering scheme. For each frame, this number is the 
same for all base stations. For transmission over the radio interface, each 
base station uses its own base station-specific offset OFSn to map the com- 

15 mon frame number to the base station's own numbering scheme. After this 
frame number mapping, the BS can send the frame at the correct point of 
time. The base stations also perform reverse mapping in the uplink direction, 
whereby the diversity combining unit in the SRNC is able to combine frames 
having a common frame number. 

20 The common frame number is also the timing reference used for 

RRC (Radio Resource Control protocol) messages, e.g. handover commands 
from the SRNC to the MS. 

According to one embodiment of the invention, one base station, 
preferably the first one involved in the connection, does not have to compen- 

25 sate for the difference between the timing references. In other words, the other 
base stations 1 timing reference is offset to match that of the first base station. 

According to a preferred embodiment of the invention, the frame 
number FN comprises two parts. One part, forming the least significant bits of 
the FN, is the known modulo-72 CFN. The other part, forming the most signifi- 

30 cant bits of the FN, can be called a Hyper Frame Number, HFN. Preferably, 
the combined length of the FN (= CFN + HFN) is at least 32 bits. This em- 
bodiment solves the third problem relating to encryption. 

When the MS sends its initial Connection Request message, it can 
set the the CFN to the BS1FN of the RACH frame in which the message was 

35 successfully sent. (A preferred initialisation value for the HFN will be presented 
later.) The SRNC receives the message in a FCL (Frame Control Layer) 



5 



frame containing also the BS1FN (=CFN), and it can initialise the MSFN to a 
correct value. The MSFN (for that specific MS) stored in the SRNC is incre- 
mented every 10 ms, even if no uplink frames are received. In practice, how- 
ever, it is sufficient to increment only the HFN every 720 ms, because the CFN 
5 is included in every uplink FCL frame. It is possible to eliminate a MS-specific 
HFN counter by 1) storing only an initial value for each MS, and 2) for each 
frame, adding to the initial value the number of completed CFN periods (at 720 
ms each) from the establishment of the connection, i.e. from the time when the 
HFN was initialised. 

10 Since the MS's timing reference is the master, the MS is at liberty to 

choose any value for the initial value of the CFN and/or the HFN. Such a de- 
gree of freedom can be used to improve the ciphering security. Instead of rig- 
idly setting the CFN and/or the HFN on the basis of the time of the Con- 
nection Request message, this point of time could be used as a seed number 

15 to a secret algorithm, for providing an initial value for ciphering such that the 
initial value is unobtainable to an eavesdropper. 

For ciphering, the parties should: 1) initialise the seed number (the 
CFN and/or the HFN) and 2) avoid using the same seed number twice or more 
within a short period of time. Re-using the same seed number could weaken 

20 the ciphering security. For example, let us assume that the mobile station uses 
the same ciphering key Kc in two subsequent RRC connections. If in both 
connections the HFN is initialised to zero, the same input to the ciphering algo- 
rithm (FN and KC) is used twice and the same ciphering mask is used in a 
relatively short period of time. This may occur also with random initialisation. 

25 According to a further preferred embodiment of the invention, ci- 

phering security is improved as follows. When the RRC connection is re- 
leased, the mobile station stores the last HFN which was used (or some other 
information from which the last used HFN can be determined). The MS may 
prevent the reuse of the same ciphering key by storing the last used HFN in its 

30 SIM card, for example. At a new RRC connection setup, the MS initialises the 
HFN to a value which is higher than the last used HFN and transmits this value 
to the SRNC, preferably in an RRC Connection Setup Request message. 
This HFN value will be used as a reference for initialising the HFN at the 
SRNC. Optimally, the next HFN is the last used HFN plus one. This ensures 

35 that there is a maximum period of time until the same ciphering key will be re- 
used. It should be noted that the RRC Connection Setup Request is only one 
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possible message for sending the initialisation value for the HFN. This value 
can be sent in any message, at any point of time, until ciphering is started. 

In order to minimise the length of the RRC connection setup mes- 
sage, it should be possible to transmit only the most significant bits of the HFN 
5 (the least significant bits having a default state, e.g. zeros). The number of bits 
used for the initialisation of the HFN depends on the number of times the 
same ciphering key can be reused when a new RRC connection is set up. 
Eight bits is probably a sufficient number for the transmitted most significant 
bits of the HFN. 

10 Before ciphering is started, (e.g. when establishing a new RRC 

connection), the HFN should be initialised to a value which is higher than the 
last used value HFN. This can be ensured as follows. When an RRC connec- 
tion is released, the MS stores the value of the last used HFN, preferably in its 
SIM card. When the next RRC connection is established, the value is read 

15 from the SIM card and incremented by one. Incrementing by one ensures that 
there is a maximum period of time until the same ciphering key will be used 
again. Naturally, the incrementing step can be performed before storing. 

Some memory can be saved by storing only the most significant bits 
of the HFN (which can be incremented before or after storing). 

20 The HFN between the MS and the UTRAN (UMTS Radio Access 

Network) can be synchronised by sending the HFN (or its most significant bits) 
from the MS to the network on a RACH channel in an RRC Connection Setup 
Request message. Alternatively, the MS could send the HFN (or its most sig- 
nificant bits) to the UTRAN: 1) using a dedicated channel; 2) during an 

25 authentication procedure; or 3) in a Ciphering Mode Complete message. If the 
network has information of the last HFN used (e.g. in an RRC connection re- 
establishment procedure), the RNC can initialise the HFN. 

In the case of a GSM to UMTS handover, a suitable message is 
Handover Complete. Alternatively, the MS could send the HFN (or its most 

30 significant bits) to the GSM network which forwards it/them to the UMTS net- 
work. 

There still exists a potential security risk. This risk may arise in a 
situation where a mobile station's power supply (battery) fails during a call. 
When the battery is recharged or replaced, and a new connection is estab- 
35 lished, the HFN (or its MSB part) will be read from the SIM card and sent to 
the network. However, if the battery fails and the mobile station does not have 
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time to store the last used HFN, the new connection (after recharg- 
ing/replacing the battery) will use the "old" HFN. As a result, the new connec- 
tion will use the same frame numbers as the previous connection did, which 
weakens security. 

5 Accordingly, it is preferable to implement the following feature: 

when the last used HFN number is read from the SIM card, it is marked "old" 
(or "used"). At the end of the connection, when the last used HFN number is 
written to the SIM card, it is marked "new" (or "unused"). If the last used HFN 
cannot be properly updated to the SIM card (e.g. due to battery failure), the 

10 mobile station will retrieve an "old" HFN number (or its MSB part). In this case, 
the mobile station has at least two options. 

According to a first option, the MS can choose a random number for 
the CFN. This random number should be significantly higher than the last used 
HFN, such that it is highly unlikely that the sequence or frame numbers will be 

15 repeated. This could be enforced if the MS updates the HFN to the SIM every 
L hyperframes and marks the recently updated HFN as "old". If the battery 
fails, the HFN for the next connection will be set to the "old" HFN (stored in the 
SIM card + L + 1. This value should be immediately updated to the SIM card 
and marked as "old". (Of course, because the HFN has a finite length, "higher" 

20 should be interpreted in a modulo fashion). 

According to a second option, the MS can inform the network that it 
has a bad HFN and request a new ciphering key Kc. When the Kc has been 
exchanged, it does not matter which HFN will be used for the first connection 
with the new Kc. 

25 It should be noted that use of the SIM card has been given only as 

an example. Any non-volatile memory will do. However, storing the HFN in the 
SIM may be preferable, considering a case where the MS user moves the SIM 
card to another terminal. 

According to yet another preferred embodiment of the invention, the 

30 frame number offsets OFSn are not integer numbers but have a higher resolu- 
tion. The fractional part of the OFS is called a Symbol Offset, SOF, and its 
resolution preferably matches one symbol or chip, if required by Layer 1 syn- 
chronisation in a soft handover procedure. Alternatively, the OFS and SOF 
can be stored as separate parameters. 
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The offsets can be updated in every measurement report. The mo- 
bile station can compare at any time its own timing reference with that of the 
base stations. 

If the invention is used in a telecommunications system where the 
5 UTMS terminology is not applicable, the Mobile Station MS and Radio Network 
Controller RNC can be called, respectively, a first and a second end node. 
Correspondingly, the Base Stations BS can be called middle nodes. The first 
middle node (BS), via which the connection is established, is called a first mid- 
dle node. The other middle-nodes, which will be added later, are called second 
10 middle nodes. 

Brief description of the drawings 

The invention will be described in more detail by means of preferred 
embodiments with reference to the appended drawing wherein: 

Fig. 1A is a block diagram illustrating a cellular telecommunications 

15 network; 

Fig 1B illustrates certain problems related to the invention; 
Fig. 2A illustrates the concept of the invention; 

Fig. 2B is a signalling diagram illustrating the operation of a pre- 
ferred embodiment of the invention; and 
20 Fig. 3 shows a case where the middle node is a controlling RNC. 

Detailed description of the invention 

Fig. 2A illustrates the concept of the invention. According to the in- 
vention, there is defined a connection-specific timing reference which is 
marked with reference number 20; The connection-specific timing reference 20 

25 comprises a connection-specific frame number CFN and, preferably, an exten- 
sion part called Hyper Frame Number HFN and a fractional offset part SOF. 

Basically, the connection-specific frame number CFN is maintained 
like any other frame number in Fig. 1B. In other words, it is stepped 
(incremented) from zero in a modulo-p manner, wherein p is the period of the 

30 counter, such as 72. A similar frame number counter is maintained for all the 
nodes involved in the connection. The only difference between the counters is 
the offset between them. In Fig. 2A, the Mobile Station MS and the RNC syn- 
chronise their frame numbers MSFN, RNCFN to the connection-specific frame 
number CFN. In regard to the CFN, Base Station BS1 has a BS-specific offset 

35 BS1 of +2, because 2 must be added to BS1's frame number BS1FN for ob- 
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taining the connection-specific frame number CFN. (Whether such an offset is 
called positive or negative is only a matter of naming convention.) Corre- 
spondingly, Base Station BS2 has a BS-specific offset BS2 = -3. (In Fig. 2A, 
such small offsets have been chosen for clarity. In reality, the offsets can have 
5 any values between 0 and 71.) According to the invention, these BS-specific 
offsets must be determined and conveyed to the base station in question, 
whereby each base station can use the offset for compensating for the differ- 
ence between its own timing reference (i.e. its frame numbering) and the con- 
nection-specific timing reference 20. 

10 The vertical box labelled CFN indicates the frame numbers at vari- 

ous points in the network. At the time shown, the connection-specific timing 
reference 20 has a frame number CFN = 5, which is also true for the MS and 
the RNC. The BS-specific frame number of BS1 is 3 and that of BS2 is 8. Be- 
cause the MS, being the master, is at liberty to choose any timing reference, 

15 and because the RNC has to synchronise its frame numbering to that of the 
MS, the MS and the RNC might as well synchronise their frame numbering 
schemes to that of BS1, which is the first base station involved in the connec- 
tion. This means that the offset for BS1, i.e. OFS1, would be zero. (However, 
the benefit of a zero offset is slight, considering that it is probably easier for 

20 BS1 simply to add the offset rather than first check whether its offset is non- 
zero, and perform the addition if the offset is non-zero.) 

The connection-specific timing reference 20 should also comprise 
an extension part, which is called a Hyper Frame Number HFN. It is stepped 
(incremented) each time the CFN completes a period, such as every 720 ms. 

25 The bit length of HFN should be rather high for two reasons. First, the 
HFN/CFN combination should be unambiguous during a connection. Second, 
the HFN/CFN combination could be used as a ciphering/deciphering key. A 
suitable length for as a ciphering/deciphering key is approximately 32 bits, 
whereby the HFN is approximately 25 bits. With such a bit length, the 

30 HFN/CFN combination is unambiguous during a connection lasting up to a 
year. 

Preferably, the connection-specific timing reference 20 also com- 
prises a fractional offset part SOF which is used to compensate for the propa- 
gation delay Td iff shown in Fig. 1B. 
35 It should be noted that term 'frame number' can be somewhat mis- 

leading. The frame numbers are not used for counting actual user frames. In- 
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stead, the base stations use the frame numbers for numbering (marking) 
uplink frames which are sent at a given point of time. They also use the frame 
numbers for determining the point of time when a downlink frame with a given 
frame number should be sent. For example, assuming that the CFN is incre- 
5 mented every 10 ms and it has a period of 72 steps (720 ms), an uplink frame 
sent 1 second (1000 ms = 100*10 ms) after establishing the connection has a 
HFN of 1 and a CFN of 28 (= 100 mod 72). Correspondingly, a downlink frame 
with a frame number of 28 must be sent 280 + n*720 ms after establishing the 
connection. In order to maintain synchronisation, dummy frames can be sent 

10 between the RNC and the BS if there is no user data to be sent. 

As stated above, according to a preferred embodiment of the inven- 
tion, the last used HFN is stored in the mobile station's SIM card after releas- 
ing an RRC connection. When a new next RRC connection is being estab- 
lished, the MS sends the SRNC an initialisation value, on the basis of which 

15 the SRNC sets initialises the HFN to a value which is higher than the last used 
HFN. Since the HFN has a finite length, "higher" should be interpreted in a 
modulo fashion. For example, let us assume a length of 25 bits for the HFN. 
Some memory can be saved and the connection establishment messages can 
be shortened by storing and sending only the most significant bits of the HFN. 

20 The MS could only store eight most significant bits. Let us call these 8 bits the 
MSB part of the HFN. At the next connection establishment, the 17 least sig- 
nificant bits (the LSB part) will not be known. However, if the MSB part is in- 
cremented by one (between two consecutive RRC connections), the first HFN 
of the new connection will certainly be higher than the last HFN of the previous 

25 connection. An identical result is achieved if the LSB part is assumed to be all 
ones and the entire HFN (not just the MSB part) is incremented by one. 

Fig. 2B is a signalling diagram illustrating the operation of the pre- 
ferred embodiment of the invention. At step 200, the MS initiates a connection 
by sending a message called RRC_Connection_Request (RRC = Radio Re- 

30 source Control protocol). This message contains the measurements of the 
base stations which the MS proposes to be included in its active set. The 
measurements comprise the apparent power and the timing reference (a 
frame number offset) of each base station. At step 202, the connection request 
is conveyed to the serving Radio Network Controller SRNC. At step 204, the 

35 SRNC sends a Channel Activation command to BS1. This message includes 
the frame numbering offset value for BS1, i.e. OFS1. However, since BS1 is 
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the first base station involved in the connection, its offset value OFS1 can be 
set to zero, because it is not necessary to synchronise the frame numbers of 
the base stations to an absolute timing reference. Instead, it is sufficient to 
synchronise the frame numbers of the various base stations with each other. 
5 (Next, BS1 sends an acknowledgement to SRNC, but it is irrelevant for under- 
standing the invention.) At steps 206 - 208, a Connection_Request_Ack is 
sent via BS1 to the MS. Now, a connection has been established between the 
MS and the SRNC. 

At step 210, the- MS sends its first uplink frame. At step 211, BS1 

10 calculates the Connection Frame Number CFN, based on the point of time 
when it receives the frame. BS1 also adds its frame numbering offset OFS1 to 
the CFN, but OFS1 was set to zero and the CFN does not change. At step 
212, BS1 sends this frame to the SRNC. Steps 214 - 216 depict the corre- 
sponding steps for sending downlink data. 

15 The MS must constantly monitor its neighbouring base stations. At 

step 220, it sends the SRNC a Measurement Report which (in this example) 
comprises measurement data for BS1 and BS2. The measurement data com- 
prises measured power and the frame number offset of BS1 and BS2. At step 
222, the SRNC decides that the MS receives BS2 strongly enough for adding 

20 BS2 into the MS's active set. At step 224, the SRNC sends BS2 a Channel 
Activation command which comprises the frame numbering offset OFS2 for 
BS2. At step 226, the SRNC sends the MS an Active Set Update message 
which commands the MS to include BS2 in its active set. (The Active Set 
Update message is somewhat analogous to a handover message, but the cur- 

25 rent base station(s) is/are not necessarily abandoned.) 

At step 230, the MS sends another uplink data frame. This time, the 
frame is relayed by to base stations, BS1 and BS2. At step 231, each base 
station determines its Base Station specific Frame Number BS1FN, BS2FN, 
based on the point of time when it receives the frame, and adds its own frame 

30 numbering offset OFSn to the BSnFN (n={0, 1}). The sum of these OFSn and 
BSnFN is the Connection Frame Number CFN. The CFN has no base station 
specific index because it is the same at both/all base stations of the connec- 
tion. At step 232, BS1 and BS2 send the uplink frame to the SRNC, the com- 
bining unit of which can correctly combine the frames because the CFN is the 

35 same in both frames. 
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The actual combining step can be based on known macrodiversity 
techniques. Each frame may contain measurement results, such as a Bit Error 
Ratio BER or a Received Signal Strength Indication RSSI, and of similarly 
numbered frames, the combining unit can choose the one that has the best 
5 measurement result. 

Steps 234 to 236 depict sending a downlink data to the mobile sta- 
tion MS. At step 234, the SRNC sends a downlink data frame having a con- 
nection frame number CFN to both/all base stations which are included in the 
mobile station's active set- At the SRNC, the CFN of downlink frames is de- 

10 termined on the basis of the point of time when the SRNC sends the downlink 
frame. At step 235, the base stations BS1 and BS2 use the CFN for deter- 
mining the point of time when they must send the downlink frame to the mobile 
station. In Fig. 2B, this calculation of time is shown as a step of subtracting the 
base station specific offset OFSn from the connection frame number CFN, the 

15 result being the base-station specific frame number BSnFN, which has a well- 
defined relationship to the point of time when the frame must be sent to the 
MS. As has been described, the BSFN specifies the time within a 720-ms cy- 
cle. In addition to knowing the BSFN, the base station must maintain the Hy- 
per Frame Number HFN which specifies the most significant bits of the time. 

20 Next, at step 236, the base stations BS1 and BS2 send the downlink data 
frame to the mobile station MS. The different base station specific offsets 
OFSn compensate for the difference between the timing references of the 
base stations, and they send the frame at the correct point of time. 

In Fig. 2B, uplink and downlink frames are sent individually. How- 
25 ever, in practice, several frames (e.g. 4) are combined into one Transport 
Block Set TBS for improving ciphering security and immunity against transmis- 
sion errors. Instead of including the CFN and/or timing adjustment information 
in each frame, it is sufficient to include such information in each TBS. 

Layer 1 symbol synchronisation 

30 In the current vision of UMTS, downlink Layer 1 data to be com- 

bined must be received with a timing difference which is less than one symbol 
period. In order to achieve such sub-symbol-period synchronisation, a proce- 
dure analogous to determining the frame number offsets can be applied. The 
MS measures the symbol offset SOFn of candidate cells/base stations. The 

35 SOF is measured as the difference between the MS-specific required frame 
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timing and the BS's downlink perch (broadcast) channel frame timing, and it is 
included in the measurement report. After deciding to add a new base station 
to the MS's active set, that BS's SOFn is conveyed to the BS in question in the 
channel activation message. 
5 Due to frequency drifts, it may be necessary to update the SOF 

during a connection. In this case, the MS may measure/recalculate the SOF 
and report it in the measurement report. The expected rate for the SOF recal- 
culation is in the order of once per 10 minutes. 

Instead of using-a separate frame number OFS and a symbol offset 
10 SOF, these two offsets can be combined to a float number, of which the inte- 
ger part specifies the OFS and the decimal part specifies the SOF. 

SRNC relocation 

During a connection, the RNC serving the MS may change. In Fig. 
1A, the broken arrow depicts the MS's movement to a cell served by BS4 

15 which is under control of RNC2. Such a situation requires SRNC relocation. In 
a SRNC relocation process, the frame numbering system (i.e. the MSFN) must 
be preserved. The CFN part can be maintained in the new SRNC because of 
uplink FCL frames. However, the HFN should be transferred to the new SRNC 
over the lur interface. The HFN can be transferred in an RNSAP SRNC relo- 

20 cation procedure. If the maximum transfer delay of the two messages via the 
core network exceeds the CFN period of 720 ms (this can happen especially if 
MAP-E is involved), some additional measures must be taken. For example, 
assuming that the old and new RNC are synchronised to a common time ref- 
erence, it is sufficient to inform the new RNC about the point of time when the 

25 HFN was initialised. 

Common channel state 

A MS may enter Common CHannel state (CCH) during a connec- 
tion, when little data needs to be transferred between the MS and the SRNC. 
In common channel state, certain access channels, such as the Random Ac- 

30 cess Channel RACH and Forward Access Channel FACH channels are 
shared between severalmobile stations. At any point of time, some of the mo- 
bile stations may use ciphering while some do not. In this case, the use of ab- 
solute frame number references is necessary only for ciphering purposes, be- 
cause macrodiversity is not used. In other words, frames are sent between the 

35 MS and the RNC via only one base station, and the MS can be allowed to use 
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the frame numbering of that base station. If the BS is changed due to hando- 
ver, the CFN should be changed to that of the new BS. 

On the RACH f the MSFN is used for ciphering data, although some 
RACH signalling messages (or at least parts of them) are sent unciphered. On 
5 the FACH (or any downlink common channel, such as Downlink Shared 
Channel, DSCH), the MSFN is used for scheduling and retransmission in the 
SRNC. The MAC layer knows the BSFN and/or the CFN and uses the MSFN 
for ciphering data on the FACH. Preferably, on all common channels, there 
should be an indication- {e%g. on a MAC layer header) whether or not the 

TO packet in question is ciphered. 

If the RNC is using a timing reference which was established before 
entering the CCH state, it may not know exactly the frame number which cor- 
responds to the point of time when the BS will send a downlink frame to the 
MS. This makes frame-number-based ciphering/deciphering virtually impossi- 

15 ble because the MS may receive the frame at a point of time which corre- 
sponds to a frame number different from the frame number which the RNC 
used for ciphering. Accordingly, it is proposed that at least in a case where the 
BS cannot send a frame at a point of time which corresponds to a frame num- 
ber indicated by the RNC, the RNC sends the frame to the MS and provides it 

20 with an appropriate correction field. For instance, if the CFN indicated by the 
RNC is 36 and the BS sends the frame at a point of time which corresponds to 
a CFN of 38, the BS should indicate to the MS that the frame was delayed by 
an amount of time which corresponds to two frame numbers. 

Such a correction field could be limited to non-negative values This 

25 means that if the frame number is not what the RNC indicated, the frame is 
delayed. If the frame number indicated by the RNC is too high, the BS could 
correct the problem by delaying the frame. 

Using an appropriate correction field is also applicable in a case 
where a Controlling RNC (CRNC, the RNC controlling a BS) decides which ra- 

30 dio frame shall be used for transmission, but the ciphering has already been 
performed by a Serving RNC (SRNC). Such a situation is shown in Fig. 3. In 
this case the CRNC is the middle node according to the invention. 

Alternatively, sending the correction field could be avoided if the ci- 
phering/deciphering algorithm is such that the MS can figure out whether or 

35 not a frame can be correctly deciphered (e.g. by providing a meaningless re- 
sult if not). In this case the MS may, upon encountering an incorrect decipher- 
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ing result, decipher the frame using the key which corresponds to the few pre- 
vious frames. 

Changes to UMTS proposals 

5 If the invention is applied in a cellular telecommunications network, 

such as UMTS, some changes to current standard proposals will be needed. 
The RRC protocol should be extended for conveying the base station-specific 
offsets (OFS, and preferably, SOF for L1 timing) in the Measurement Report 
for the candidate cells. For some base stations these measurement values 
10 change very slowly or, for practical purposes, they do not change at all, and 
thus some overhead can be eliminated by sending the offsets only as neces- 
sary. 

The FCL protocol should include the CFN in every uplink and down- 
link frame. For maintaining synchronisation, uplink frames should be sent 
15 regularly, even if there is no data to be sent (DTX). Dummy frames can be 
used for initial synchronisation. One or more time adjustment bits can be in- 
cluded in the FCL header. The format of the header can be bearer-specific. 

The BSAP protocol should include the OFS/SOF in the Channel 
Activation message and in the Channel Modification message, if used. A 
20 new message/procedure, Transmission failure/Error Indication should be 
defined for indicating that a base station has received a frame completely out 
of the time slot allocated for the frame. 

The RNSAP protocol should include the OFS/SOF in the Branch 
Addition and Branch Reconfiguration messages. Similar to the BSAP pro- 
25 tocol, a new message/procedure, Transmission failure/Error Indication 
should be defined. 

The RANAP protocol should include the HFN (or the point of time 
when the HFN was initialised) in SRNC Relocation and SRNC Relocation 
Request messages. 

30 The Radio Network Controller RNC should include on the MAC 

layer a Hyper Frame Number HFN counter for each mobile station. Actually, 
an MS-specific counter is only needed as a logical concept. In practice, it is 
not necessary to establish a separate counter for each mobile station. Alterna- 
tively, for each mobile station, the RNC could store the point of time when the 

35 connection was established, and when the HFN number is needed, its initial 
value is retrieved and added to the current duration of connection (in units of 
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720 ms cycles). The HFN can be used as an input to the ciphering/deciphering 
algorithm. Preferably, the RNC should also store the SOF/Tdiff (see Figs. 1B 
and 2A) for each mobile station and modify it according to the timing advance 
bits in FCL uplink frames. This information is used for setting the transmission 
5 time of the FCL downlink frames and for setting a switching time for operations 
involving L1/L2 reconfiguration. 

The Base Stations BS should store, for each mobile station, the 
BS-specific frame numbering offset OFS (and a separate symbol offset SOF if 
it is not included in the OFS). The BS should include the CFN = BSFN + OFS 

10 in every uplink data frame and transmit the downlink data frames at the point 
of time which corresponds to BSFN = CFN - OFS. (In these additions and 
subtractions, the SOF is assumed to be included in the OFS.) Moreover, the 
base stations should set the timing adjustment bit(s) in uplink FCL frames. 

The Mobile Station MS should initialise a MS-specific frame number 

15 MSFN and increment it every 10 ms. It should also measure the OFS and SOF 
of base stations within range (in addition to the prior art measurements), and 
report these offset parameters in its measurement reports. 

For illustrating the invention, and for demonstrating its industrial ap- 
plicability, the invention has been described in connection with a 3rd genera- 
20 tion mobile telecommunications system, such as UMTS. However, the inven- 
tion is applicable in other types of communications systems and, conse- 
quently, it is not limited to the embodiments described above. 

Glossary (some acronyms are not official): 

BSn: Base Station number n 
25 BSAP: BS Application Part protocol 

BSnFN Frame Number used by Base Station number n 

CCH: Common CHannel (state) 

CFN: Connection Frame Number 

DTX: Discontinuous Transmission 
30 FACH: Forward Access Channel 

FCL: Frame Control Layer (a frame transmission protocol) 

HFN: Hyper Frame Number, extension of CFN 

MAC: Medium Access Control 

MS: Mobile Station, also called User Equipment (UE) 
35 OFSn: Frame number offset of BS number n 
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RACH: Random Access Channel 

RANAP: RAN (Radio Access Network) Application Part 

RNC: Radio Network Controller 

RNSAP: Radio Network System Application Part (signalling protocol between 2 RNCs) 
SOFn: Symbol Offset, can be presented as fractional part of OFSn 
SRNC: Serving RNC 
TBS: Transport Block Set 

UMTS: Universal Mobile Telecommunications System 
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Claims 

1. A method for synchronising transmission of frames in a telecom- 
munications network comprising a first end node (MS), a second end node 
(SRNC), at least one middle node (BS1, BS2) via which a connection is estab- 

5 lished between said end nodes (MS, SRNC), wherein said first end node (MS) 
and said at least one middle node (BS1 t BS2) have a corresponding timing 
reference (MSFN, BS1FN, BS2FN); 

characterized in that the method comprises the steps of: 
establishing a- connection-specific timing reference (CFN) which is 
10 common to all nodes (MS, BS1, BS2, RNC) involved in said connection; 

determining, for at least one middle node (BS1, BS2) an offset 
(OFS, SOF) which is related to the difference between the timing reference of 
the middle node in question and said connection-specific timing reference 
(CFN); and 

15 using said information about said offset to compensate for said dif- 

ference between said timing references. 

2. A method according to claim 1, characterized in that said 
offset is used by the at least one middle node (BS1), for synchronising its tim- 
ing reference to that of the second end node (RNC). 

20 3. A method according to claim 1 or 2, characterized in that 

the network comprises a first middle node (BS1) via which the connection is 
established and at least one second middle node (BS2, BS3); and that said 
offset is used by at least each second middle node (BS2, BS3). 

4. A method according to any one of the preceding claims, char- 
25 acterized in that the end nodes (MS, SRNC) synchronise their timing ref- 
erences based on the time when a predetermined message (200, 202) is sent 
between them. 

5. A method according to claim 4, characterized in that in 
that the end nodes (MS, SRNC) synchronise their timing references based on 

30 the time when the connection between them is established. 

6. A method according to any one of the preceding claims, char- 
acterized in that the connection-specific timing reference comprises, at 
said end nodes (MS, RNC): 
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a connection-specific frame number (CFN), which is stepped at 
predetermined intervals and which has a finite length such that the connection- 
specific frame number (CFN) has a period which is substantially shorter than 
the duration of a typical connection; and 

a frame number extension (HFN) which is stepped when the con- 
nection-specific frame number completes one period. 

7. A method according to claim 6, characterized in that the 
end nodes use the connection-specific frame number (CFN) and the frame 
number extension (HFN) for ciphering and deciphering the frames. 

8. A method according to any one of the preceding claims, char- 
acterized in that each middle node (BS) uses the connection-specific 
timing reference for determining the time of transmission towards the first end 
node (MS) and/or for determining a frame number for frames towards the sec- 
ond end node (SRNC). 

9. A method according to claim 8, characterized in that in a 
case where a middle node (BS) can only send a frame at a point of time which 
is later than the time which corresponds to the connection-specific timing ref- 
erence, the middle node in question provides the frame with a correction indi- 
cator, which indicates, directly or indirectly, the amount of time by which the 
frame was delayed. 

10. A method according to claim 8 or 9, characterized in that 
the offset for the middle node in question also comprises a fractional offset 
part (SOF) which approximately corresponds to the propagation delay of a 
frame between said end nodes (MS, SRNC). 

11. A method according to any one of the preceding claims, 
characterized in that the first end node (MS) obtains measurement re- 
sults of the middle nodes (BS) and sends the measurement results to the sec- 
ond end node (SRNC); and the second end node (SRNC) uses the measure- 
ment results for determining said offset for the middle node in question. 

12. A method according to any one of the preceding claims, 
characterized in that end nodes (MS, SRNC) synchronise their timing 
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references to the timing reference of one of said at least one middle node 
(BS1, BS2) involved in the connection. 

13. A method according to claim 12, c h a r a c t e r i z e d in that 
end nodes (MS, SRNC) synchronise their timing references to the timing ref- 

5 erence of the first middle node (BS1) involved in the connection. 

14. A method according to any one of the preceding claims, 
characterized in that the first end node is a mobile station (MS), each 
middle node is a base sTatfon (BS1, BS2) and/or a controlling radio network 
controller, and the second end node is a serving radio network controller 

10 (SRNC). 

15. A method according to any one of the preceding claims, 
characterized in that at least some frames comprise an indication 
which indicates whether or not the frame in question comprises ciphered data. 

16. A method according to claim 6, characterized in that the 
15 first end node (MS) sends to the second end node (RNC) an initialisation pa- 
rameter for said frame number extension (HFN), and on the basis of said ini- 
tialisation parameter, the second end node (RNC) initialises said frame num- 
ber extension (HFN) to a value which exceeds the last value of said frame 
number extension (HFN) during a previous connection. 

20 17. A method according to claim 16, characterized in that 

said initialisation parameter is formed of a number n of most significant bits in 
said last value of said frame number extension (HFN), wherein n is between 
25 and 50 per cent of the number of bits in said frame number extension 
(HFN). 

25 1 8. A method according to claim 16 or 17, characterized in 

that the first end node (MS) sends said initialisation parameter in response to 
a detected need for establishing, re-establishing or handing over a connection. 

1 9. A method according to any of claims 16 to 18, character- 
ize d in that the first end node (MS) sends said initialisation parameter to the 
30 second end node (RNC) in one or more of the following ways: 

on a RACH channel, preferably in an RRC Connection Setup 
Request message; 
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on a dedicated channel; 

in a message relating to an authentication procedure; or 
in a Ciphering Mode Complete message. 

20. A method according to any one of claims 16 to 19, charac- 
5 t e r i z e d in that in the case of a handover from a second generation mobile 

network to a third generation mobile network, the first end node (MS) sends 
said initialisation parameter to the second end node (RNC) in a Handover 
Complete message. 

21 . A method according to any one of claims 16 to 19, charac- 
10 t e r i z e d in that in case of a handover from a second generation mobile net- 
work to a third generation mobile network, the first end node (MS) sends said 
initialisation parameter to said second generation mobile network which for- 
wards it to the second end node (RNC). 

22. A method according to any one of claims 16 to 21, charac- 
15 t e r i z e d in that: 

at the end of a connection, the first end node (MS) stores into a 
memory a value which comprises information about the last frame number 
extension (HFN) used during the connection in question; and 

at the beginning of the next connection, the first end node (MS) 
20 reads from the memory the value stored in the previous step and uses said 
value for forming said initialisation parameter. 

23. A method according to claim 22, characterized in that 
said storing step comprises marking the stored value with an unused status 
and said reading step comprises marking the stored value with a used status. 

25 24. A first end node (MS) for forming a connection to a second end 

node (SRNC) via at least one middle node (BS1, BS2,...) in a telecommunica- 
tions network, wherein said first end node (MS) and each middle node (BS1, 
BS2) have a corresponding timing reference (MSFN, BS1FN, BS2FN); 
characterized in that the first end node (MS) is adapted to co-operate 

30 with said second end node (SRNC), for: 

establishing a connection-specific timing reference (CFN) which is 
common to all nodes involved in said connection, and 
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determining, at least for one middle node (BS1, BS2), an offset 
(OFS, SOF) which is related to the difference between the timing reference of 
the middle node in question and the connection-specific timing reference 
(CFN). 

25. A first end node (MS) according to claim 24, character- 
ized in that said connection-specific timing reference comprises: 

a connection-specific frame number (CFN), the value of which is 
stepped at predetermined intervals and which has a finite length such that the 
connection-specific frame number (CFN) has a period which is substantially 
shorter than the duration of a typical connection; and 

a frame number extension (HFN) which is stepped when the con- 
nection-specific frame number completes one period; and that 

when a connection is being established, re-established or handed 
over, said first end node (MS) is adapted to send to the second end node 
(RNC) an initialisation parameter for said frame number extension (HFN), for 
initialising said frame number extension (HFN) to a value which exceeds the 
last value of said frame number extension (HFN) during a previous connection. 

26. A second end node (SRNC) for forming a connection to a first 
end node (MS) via at least one middle node (BS1, BS2,...) in a telecommuni- 

20 cations network, wherein said first end node (MS) and each middle node (BS1, 
BS2) have a corresponding timing reference (MSFN, BS1FN, BS2FN); 

characterized in that the second end node (SRNC) is 
adapted to: 

co-operate with said first end node (MS), for establishing a connec- 
25 tion-specific timing reference (CFN) which is common to all nodes involved in 
said connection, and for determining, at least for one middle node (BS1, BS2), 
an offset (OFS, SOF) which is related to the difference between the timing ref- 
erence of the middle node in question and the connection-specific timing ref- 
erence (CFN); and 

30 use said information about said offset to compensate for said differ- 

ence between said timing references. 

27. A second end node according to claim 26, characterized 
in that the second end node (SRNC) is adapted to convey £aid information 
about said offset to the middle node in question. 



10 



23 

28. A middle node (BS1, BS2) for forming a connection between a 
first end node (MS) and a second end node (SRNC) in a telecommunications 
network, wherein data is sent between said end nodes (MS, SRNC) in frames 
at least some of which are sent via several middle nodes (BS1, BS2); and 
5 wherein said first end node (MS) and each middle node (BS1, BS2) have a 
corresponding timing reference (MSFN, BS1FN, BS2FN); 

characterized in that the middle node is adapted to synchro- 
nise to a connection-specific timing reference (CFN) by: 

receiving an offset (OFS, SOF) which is. related to the difference 
10 between its own timing reference and the connection-specific timing reference 
(CFN); and 

using said offset to compensate for said difference between said 
timing references. 
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(57) Abstract 

A mechanism for synchronising transmission of frames in 
a telecommunications network comprising a mobile station 
(MS), a radio network controller (SRNC), at least one base 
station (BS1, BS2). The mobile station (MS) and each 
base station (BS1, BS2) have a corresponding timing ref- 
erence (MSFN, BS1FN, BS2FN). The mechanism com- 
prises or performs the steps of 1) establishing a connec- 
tion-specific timing referejtce (CFN) which is common to 
all nodes (MS, BS1 , BS2, RNC) involved in the connec- 
tion; 2) determining, for the base stations (BS1, BS2) an 
offset (OFS) between the timing reference of the base 
station in question and the CFN; and 3) using the offset 
(OFS) in the base stations (BS1, BS2), to compensate for 
the difference between the timing references. 
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